Tomáš Pospíšek's Notizblock
Ich dachte immer, Software Architekten seien jene Leute, welche in Visio oder Rational Rose arbeiten, viereckige, beschriftete, mit Linien verbundene Kästchen malen und UML den Rang eines zu erlernenden Standards zusprechen.
Dass diese Rolle offenbar weitverbreitet auch so verstanden wird, ist sehr problematisch, da Coden oder Proof-of-Concept Prototypen Basteln dann aus dieser Warte nicht standesgemäss ist.
Das Wort Architekt lügt in diesem Falle, da es suggeriert, dass SW Architektur essentiell ähnlich dem herkömmlichen Architekten sei, welcher einen Plan zeichnet, der dann von einer Baufirma ausgeführt wird.
SW ist aber insofern fundamental anders als das Bauwesen, als dass ein grosser Teil dessen, was erstellt wird neu ist und also so noch nie getestet wurde. Hingegen sind alle Teile eines Hauses Massenprodukte und auch die Baustatik ist eine wohl bekannte Disziplin, welche in der Regeln nichts neues erfindet.
Die fachliche Logik der SW entsteht in der Regel neu und ausserdem besteht eine der grössten Schwierigkeiten darin überhaupt herauszufinden, ob denn das was an SW entsteht überhaupt dem entspricht, was der Kunde eigentlich meint.
Natürlich gibt es einen grossen Fundus an SW (Bibliotheken aka Libraries), welche wiederverwendet werden kann. In der Regel ist diese Bauteile aber niemals so stabil, zuverlässig und robust, wie die vorgefertigten, bzw. Standard-Teile der Baubranche.
Daraus folgt, dass die Erwartung, ein Architekt könne einen Entwurf machen, welcher dann implementiert wird, irgendwo zwischen naiv und realitätsfremd liegt. In der Regel muss die Software Entwicklung mehr oder weniger iterativ durchgeführt werden, d.h. erst während der Implementierung können Fehler und Fehlannahmen entdeckt und im optimalen Falle von der Architektur für einen verbesserten Entwürf verwendet werden.
Woraus wiederum folgt, dass der SW Architekt v.a. dafür sorgen sollte, dass das Gesamtbild dessen, was gemacht werden soll, in grossen Zügen einigermassen bekannt ist. Damit der Architekt seinen Entwurf auch nur im Ansatz realistisch gestalten kann, muss er recht grosse Erfahrung mit jeglicher eingesetzter Technologie haben, bzw. in einzelnen Bereichen auf den Rat von Technologiespezialisten zurückgreifen.
Weiterhin muss er dafür sorgen, dass die Entwickler Ihre Teile gut in das Gesamtbild eingepasst liefern, und dass sie sich an die vorgegebenen Leitplanken halten. Insofern hat er die Rolle des Vorarbeiters der Baubranche inne.
Die Fähigkeit Software von guter Qualität zu offeriertem Preis und innerhalb der angegebenen Zeit abzuliefern, hängt neben dem Glück, dass "aus dem Nichts" keine Unbekannten auftauchen, somit von der Stabilität der einzelnen Mitglieder und deren fein abgestimmtem Zusammenspiel ab, d.h. deren guten gegenseitiger Kenntnis und entsprechdem Arbeitsverhältnis.
Der Architekt muss die Viereckchen so zeichnen können, dass sie seinen Entwicklern genug Bewegungsfreiheit lassen, dass sie diese nicht überfordern und dass das ganze Bild robust gegen das Wackeln der einzelnen Viereckchen ist. Er muss stark genug sein, seinen Entwurf zu verteidigen, muss aber auch gut zuhören können, um in der Folge das Bild möglicherweise radikal umzustellen.
Ein weiterer fundamentaler Unterschied zu Bauwerken: Software ist meistens nie fertig - somit muss der Architekt einen festen Augemerk darauf verwenden, dass die Software auch über längere Lebensdauer nicht verwest und hässlich wird, und dass die Strukturen, die er entworfen hat einem längerfristigen Wachstum dienen bzw. standhalten. Einem Wachstum während dem womöglich ein grosser Teil des Baumaterials im Laufe der Zeit ersetzt und oder verändert wird.
(entstanden aus einem Gespräch mit Bernhard Pfund)
Tomáš Pospíšek, 2009-01-26
